The sheer quantity of machine-type communications (MTC) devices, also known as machine-to-machine (M2M) communications device will far exceed devices using human-to-human (H2H)-based communications in the very near future. A MTC application at this present time may already involve more than 1000 subscriptions for a single user, and also a MTC application would generally target a group device. Hence, from vantage point of both a customer and an operator, it would be beneficial to optimize the handling of MTC devices as a group since group based messaging may efficiently distribute the same message, such as a trigger request, to members belonging to a same MTC group located in a particular geographical area in response to a request from a service capability server (SCS). Triggering by groups would substantially reduce the number of triggering messages sent through a network.
One way to implement group based MTC messaging could be to utilize an existing point to multi-point transmission service such as the multimedia broadcast/multicast services (MBMS). As described in 3GPP SA2 TR 23.887, MTC Group Messaging using MBMS is specified in section 8.1.3.2. Accordingly, a network operator could treat a device trigger message as a normal MBMS user message. However, MBMS has conventionally been used for multimedia transmissions. If MBMS were to be utilized to accommodate MTC group messaging features, the MBMS would need to be prepared to receive large quantities of small data as group message. Therefore, enhancing small data transmission through MBMS could be a high priority.
FIG. 1A illustrates a plurality of cells served under a MBMS service area. With MBMS, the same data would be able to be transmitted to multiple devices located within a specific area which would be referred to as a MBMS service area. Under a MBMS service area, there could be one or more MBMS Single-Frequency Network (MBSFN) under which a number of synchronized cells could be covered.
FIG. 1B illustrates a typical MBMS architecture. In the MBMS architecture, there would be a content provider or a MTC server or a GCSE application server which provides a MBMS data directly from the server or through a SCS. The MBMS data from the content provider would be delivered to a Broadcast Multicast Service Center (BM-SC) which would typically be located in a core network and would perform authentication/authorization of the content provider. The BM-SC would then deliver the MBMS data via a SGmb/SGi-mb interface to a MBMS gateway (MBMS-GW) which processes IP-packets from the BM-SC and delivers control information through a Mobility Management Entity (MME) via a M3 interface to a Multi-cell/Multicast Coordination Entity (MCE) in a radio access networks (RAN). In other words, the MBMS data would be delivered through a user plane such as through the M1 interface while control information would be delivered through a control plane such as through a MME, a MCE, and then to an eNB via a Sm interface, M3 interface, and M2 interface respectively. The MCE would coordinate the radio resource according to the received control information within a MBSFN area and in turn would send control signaling to one or more base stations through a M2 interface. The MBMS GW would also send MBMS data directly via M1 to one or more base stations which delivers the MBMS data to UEs under its domain.
FIG. 1C illustrates an example of reading user data from the conventional multicast channels (MCHs) in MBSFN subframe view in accordance with the typical MBMS architecture of FIG. 1B. Currently in a Long Term Evolution (LTE) system, the duration of a radio frame is 10 ms. Here we assume every radio frame would contain 1 MBSFN subframe, and therefore would be a 10 ms interval between two MBSFN subframes. MBSFN data would be transmitted through a MCH which includes a multicast traffic channel (MTCH) transmitting MBMS user data and a multicast control channel (MCCH) transmitting control information including subframe allocation information and modulation and coding schemes. The conventional reading procedure would require a UE to read system information block (SIB) 13 to obtain the multicast control channel (MCCH) configuration in MBSFN-AreaInfo first in order to find the corresponding MCH scheduling information (MSI) which indicates the location of the multicast traffic channel (MTCH) within which any particular MBMS user data would be located, and then a UE would be able to obtain the MBMS user data from the MTCH. A convention MCCH would only contain control information such as MCH configuration which points out how MBMS data could be received in MTCH. Since the MCCH, MTCH, and MSI are all located in the Multimedia Broadcast multicast service Single Frequency Network (MBSFN) subframe which is configured in System information block type 2 (SIB 2), the latency of reading MTCH could be tens or even hundreds of micro seconds delays. As shown in the example of FIG. 1C, reading user data #8 and #10 in response to reading MSI values would require 100 ms and 130 ms respectively.
As Group Communication System Enabler over LTE (GCSE_LTE) endeavors to develop the critical communication which would involve public safety over the LTE system, the system has been recommended to provide a mechanism to support a group communication end to end setup time of less than or equal to 300 ms, which could prove useful while transmitting urgent information. Therefore, minimizing the latency of reading MTCH could be a crucial step toward minimizing the above mentioned call setup time.